MemoryBrowserController.m and PokeMemoryController.m both declared
`id notificationObserver;` at file scope without `static`. The two
translation units emit common symbols (nm against the .o files
shows `C _notificationObserver` in each); the linker merges them
despite GCC_NO_COMMON_BLOCKS=YES on the target, so the controllers
share one storage slot for their addObserverForName: tokens.

Latent while runModal forbade simultaneous visibility — the slot
always held the token of whatever window was currently closing.
Reachable now that the windows coexist: open Memory Browser, open
Poke Memory (lazy init writes PM's token into the now-MB-occupied
slot), close Memory Browser first. MB's block reads the slot,
finds PM's token, removes PM's observer. The next Poke Memory
close has no observer to fire — unpause never runs and
fuse_emulation_paused leaks, freezing the emulator.

Adding `static` to both declarations gives each translation unit
private storage. nm now reports `d _notificationObserver` in each
.o file.

Until this fix the first time the user opened Pokes/Cheats in a
session the emulator kept running. Visible symptoms, in order of
how likely the user is to notice them:

* Memory Browser open, then Pokes/Cheats: closing Pokes/Cheats
  resumed the emulator with Memory Browser still on screen, and
  the browser's snapshot started drifting against live memory.

* Pokes/Cheats opened alone: z80 kept executing while the user
  enabled cheats, so a poke could be partially overwritten by the
  game's own code before it stuck.

* Once Pokes/Cheats had been opened and closed once, subsequent
  utility windows (Memory Browser, Rollback, etc.) stopped
  pausing the emulator — they opened normally but showed a live,
  drifting view instead of the expected snapshot. The defect
  persisted until the next app launch.

Root cause: PokeMemory.xib was the only utility xib without
visibleAtLaunch="NO" (the attribute defaults to YES when omitted).
PokeMemoryController.init touches [self window] to register a
close-notification observer, which lazy-loads the xib; with
visibleAtLaunch=YES, NSNib orders the window front during the
load. By the time showWindow: ran, isVisible was already YES, so
its early-return guard returned without calling pause. The close
block still called unpause unconditionally, walking the pause
counter down by one each cycle.

Adding visibleAtLaunch="NO" to PokeMemory.xib lines it up with
the other utility xibs. releasedWhenClosed="NO" is added for the
same consistency; NSWindowController already forces it at runtime.

JoystickConfigurationController previously did its parent-child
teardown in -cancel:, leaving the red-X dismissal path (and the
Preferences-close cascade) without a removeChildWindow:. The stale
relationship was reconciled on the next showWindow: by the parent
check, so the bug was invisible in practice — but the asymmetry
diverged from the close-path matrix in spec 004 which mandates a
single teardown hook for every closable-with-pause-or-parent panel.

Add an NSWindowWillCloseNotification observer in showWindow:; route
the unpin through handleWillClose: so every dismissal path (Apply,
Cancel, red X, Preferences close cascade) does the same teardown.

Joystick is the only utility window whose showWindow: can run a
second time without an intervening close: re-clicking Configure for
the other joystick reuses the same instance, switching contents via
sender's tag. The spec explicitly disallows a singleton early-return
guard here. To keep observer registration idempotent across that
switch, remove any prior registration before adding.

PreferencesController.handleWillClose: runs read_config_file,
machine reselection, scaler hotswap, [machineRomsController
setContent:nil], and [machineRoms release] alongside removing its
NSWindowWillCloseNotification observer. When [NSApp terminate:]
cascade-closes the windows with Preferences still open, the
WillClose notification fires the handler and one of those teardowns
reaches into NSWindow's notification observer table while it is
still being walked. _platform_strcmp segfaults inside
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__.

Latent in the runModal era: the modal session blocked Cmd+Q
delivery, so the user could not quit with Preferences open.
Removing runModal reaches this path.

Register a class-target observer for
NSApplicationWillTerminateNotification (which fires before the
close cascade), set a file-static flag, and short-circuit
handleWillClose: when it is set. Settings have already been
persisted to NSUserDefaults via the binding chain by the time the
user clicks Quit, so the work being skipped is the apply-back
path: meaningless at exit and dangerous when invoked from inside
the terminate cascade.